Skip to content

feat: Add filter by UID feature by using existing --filter syntax - #3237

Open
filzrev wants to merge 1 commit into
dotnet:masterfrom
filzrev:feat-add-filter-by-uid
Open

feat: Add filter by UID feature by using existing --filter syntax#3237
filzrev wants to merge 1 commit into
dotnet:masterfrom
filzrev:feat-add-filter-by-uid

Conversation

@filzrev

@filzrev filzrev commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

This PR extend existing --filter syntax to support filter by UID of BenchmarkCase.
By modyfing existing filter logics to use UidFilter when filter text can be parsed as GUID format.

Other changes

  • Move filter related test under Filters directory/namespace.

@filzrev
filzrev force-pushed the feat-add-filter-by-uid branch from 689470f to 24e30c5 Compare August 22, 2026 09:30

@adamsitnik adamsitnik left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@filzrev I am trying to understand when filtering by guid is going to provide value.

Let's say that I have the BenchmarkDotNet.Tests.Filters.TypeWithBenchmarksAndParams.TheBenchmark benchmark and I want to run it.

If I use --filter BenchmarkDotNet.Tests.Filters.TypeWithBenchmarksAndParams.TheBenchmark it just works.

When I use UID I need to:

  • write some code that is going to generate the unique ID using GetUniqueId (not mentioned in samples or XML docs)
  • somehow store this value
  • provide the value when filtering.

Now as soon as the namespace, type name, method name or any other part of the benchmark ID changes, the UID is no longer valid. So what is the advantage of using it over the typical --filter?

@filzrev

filzrev commented Aug 24, 2026

Copy link
Copy Markdown
Contributor Author

It's intended to be used for debugging purpose. (launchSetting.json or CI input parameter)

Existing filter syntax match filterName or fullName.
So it can't distinguish BenchmarkCases that have different job.

Example

[InProcess]
[Config(typeof(DebugInProcessConfig))]
public class Benchmarks
{
    [Benchmark]
    public void Benchmark01() {}
}

And when filtering benchmarkCase with fullName.
It needs double-quote for filter value (When Params exists empty space is included on fullName)

To run specific benchmark for debugging purpose,
It's easier to specify BenchmarkCase by uid that are retrieved by --list json command.

@adamsitnik

Copy link
Copy Markdown
Member

It's intended to be used for debugging purpose. (launchSetting.json or CI input parameter)

Existing filter syntax match filterName or fullName. So it can't distinguish BenchmarkCases that have different job.

Thanks. In such case I would expect the user to modify the config and just comment out the Job they don't want to use.

@filzrev

filzrev commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

Thanks. In such case I would expect the user to modify the config and just comment out the Job they don't want to use.

I want to avoid modify/rebuild benchmark if possible.
A more specific example would be testing across multiple .NET versions, as shown below:

I want to run specific benchmark case(Job) by editing launchSettings.json.

[SimpleJob(RuntimeMoniker.Net80)]
[SimpleJob(RuntimeMoniker.Net90)]
[SimpleJob(RuntimeMoniker.Net10_0)]
public class MyBenchmark
{
    [Benchmark]
    public void Test()
    {
        // benchmark
    }
}

If reusing the --filter option is not desirable,
I want other options to execute specific benchmark case.

@adamsitnik

Copy link
Copy Markdown
Member

I want to avoid modify/rebuild benchmark if possible.

This is a great goal and that is why we should encourage users to specify all the jobs arguments via command line arguments.

My personal approach is to always have a config with the default settings I usually want (like 1 warmup iteration), with a single job marked AsDefault and all the exporters and then everything else (diagnosers, filters, tfms) specified via command like arg.

But in this particular example we talk about Debugging, which requires and IDE (at least for most of us). So I would expect the users to simply go and modify the code by commenting out the job they don't like just a moment before they hit F5.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants